16.我們可以通過瀏覽項目的源代碼樹—包含項目源代碼的層次目錄結構, 來分析一個項目的組織方式. 源碼樹常常能夠反映出項目在構架和軟件過程上的結構.
117.應用程序的源代碼樹經常是該應用程序的部署結構的鏡像.
118.不要被龐大的源代碼集合嚇倒; 它們一般比小型的專門項目組織得更出色.
119.當您首次接觸一個大型項目時, 要花一些時間來熟悉項目的目錄樹結構.
120.項目的源代碼遠不只是編譯後可以獲得可執行程序的計算機語言指令; 一個項目的源碼樹一般還包括規格說明|最終用戶和開發人員文檔|測試腳本|多媒體資源|編譯工具|例子|本地化文件|修訂歷史|安裝過程和許可信息.
121.大型項目的編譯過程一般聲明性地借助依賴關係來說明. 依賴關係由工具程序, 如make及其派生程序, 轉換成具體的編譯行動.
122.大型項目中, 製作文件常常由配置步驟動態地生成; 在分析製作文件之前, 需要先執行項目特定的配置.
123.檢查大型編譯過程的各個步驟時, 可以使用make程序的-n開關進行預演.
124.修訂控制系統提供從儲存庫中獲取源代碼最新版本的方式.
125.可以使用相關的命令, 顯示可執行文件中的修訂標識關鍵字, 從而將可執行文件與它的源代碼匹配起來.
126.使用修訂日誌中出現的bug跟踪系統內的編號, 可以在bug跟踪系統的數據庫中找到有關的問題的說明.
127.可以使用修訂控制系統的版本儲存庫, 找出特定的變更是如何實現的.
128.定制編譯工具用在軟件開發過程的許多方面, 包括配置|編譯過程管理|代碼的生成|測試和文檔編制.
129.程序的調試輸出可以幫助我們理解程序控制流程和數據元素的關鍵部分.
130.跟踪語句所在的地點一般也是算法運行的重要部分.
131.可以用斷言來檢驗算法運作的步驟|函數接收的參數|程序的控制流程|底層硬件的屬性和測試用例的結果.
132.可以使用對算法進行檢驗的斷言來證實您對算法運作的理解, 或將它作為推理的起點.
133.對函數參數和結果的斷言經常記錄了函數的前置條件和後置條件.
134.我們可以將測試整個函數的斷言作為每個給定函數的規格說明.
135.測試用例可以部分地代替函數規格說明.
136.可以使用測試用例的輸入數據對源代碼序列進行預演.
+++++++++++++++++++
編碼規範和約定
+++++++++++++++++++
137.了解了給定代碼庫所遵循的文件組織方式後, 就能更有效率地瀏覽它的源代碼.
138.閱讀代碼時, 首先要確保您的編輯器或優美打印程序的tab設置, 與代碼遵循的風格規範一致.
139.可以使用代碼塊的縮進, 快速地掌握代碼的總體結構.
140.對編排不一致的代碼, 應該立即給予足夠的警惕.
141.分析代碼時, 對標記為XXX, FIXME和TODO的代碼序列要格外注意: 錯誤可能就潛伏在其中.
142.常量使用大寫字母命名, 單詞用下劃線分隔.
143.在遵循Java編碼規範的程序中, 包名(package name)總是從一個頂級的域名開始(例如, org, com), 類名和接口名由大寫字母開始, 方法和變量名由小寫字母開始.
144.用戶界面控件名稱之前的匈牙利記法的前綴類型標記可以幫助我們確定它的作用.
145.不同的編程規範對可移植構造的構成有不同的主張.
146.在審查代碼的可移植性, 或以某種給定的編碼規範作為指南時, 要注意了解規範對可移植性需求的界定與限制.
147.如果GUI功能都使用相應的編程結構來實現, 則通過代碼審查可以輕易地驗證給定用戶界面的規格說明是否被正確地採用.
148.了解項目編譯過程的組織方式與自動化方式之後, 我們就能夠快速地閱讀與理解對應的編譯規則.
149.當檢查系統的發布過程時, 常常可以將相應發行格式的需求作為基準.